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METHOD FOR UNIDIRECTIONAL 
AND BIDIRECTIONAL LABEL 
SWITCHED PATH SETUP IN A 
LABEL SWITCHED NETWORK 

M Cross Reference to Related Applications 

IJ TIlis application claims priority to United States Provisional Application "MIXED 

ly UNIDIRECTIONAL AND BI-DIRECTIONAL LSP SETUP IN GMPLS FRAMEWORK," Serial No. 

60/293,365, filed on May 24, 2001 , the contents of which are incorporated by 
W reference herein. 

U Background of Invention 

yi • ■ 

fll 

[0001] The present invention relates to label distribution in a label switched network and, 
^ more particularly, to resolving contention In networks that permit unldireaional and 

f y 

bidirectional label switched paths. 

[0002] 

Multi-Protocol Label Switching (MPLS) is an advanced framework for high-speed 
data forwarding that differs from conventional destination-based IP routing: each 
packet is provided with a "label" that is used by label switched routers (LSRs) to 
forward the packet along what is referred to as a label switched path (LSP). See L 
Rosen et al., "Multiprotocol Label Switching Architecture," internet Engineering Task 
Force (IETF) Network Working Croup, Request for Comments (RFC) 3031 . 
http://www.ietf.org/rfc/rfc3031 .txt Oanuary 2001). LSRs inform one another of label 
bindings using a process of label distribution — otherwise known as LSP setup. See, 
e.g., L Andersson et al., "LDP Specification," IETF Network Working Group, RFC 3036, 
http://www.ietf.org/rfc/rfc3036.txt Oanuary 2001). Labels are by convention allocated 
and distributed from a downstream direction — where "downstream" in the art refers 
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to the direction of data flow. In the context of IP networks, where ISPs are assumed to 
be unidirectional, downstream label selection assures that there is no label contention 
among connection requests coming from different directions. 

[0003] Generalized MPL5 ("GMPLS"), also referred to in the art as Multi-Protocol Lambda 
Switching ("MPL(ambda)S"), extends MPLS to support — not just packet-switching 
devices — but devices that perform switching in the time, wavelength, and space 
domains. GMPLS provides the potential for a control plane that can be utilized with 
legacy equipment (e.g. SONET) as well as newer devices (e.g. optical crossconnects 
("OXCs")).See, e.g., D. Awduche et al., "Multi-Protocol Lambda Switching: Combining 
MPLS Traffic Engineering Control with Optical Crossconnects," IETF Network Working 
Group, Internet Draft, http://www.ietf.org/internet-drafts/draft-awduche-mpls-te- 
optical-01 .txt (November 1 999). For various practical reasons, current GMPLS 
signaling mechanisms permit the setup of what are referred to in the art as 
bidirectional LSPs. See P. Ashwood-Smith, et aL, "Generalized MPLS — Signaling 
Functional Description," IETF Network Working Group, Internet Draft, 
http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-signaling-01 .txt 
(November 2000). The introduction of bidirectional LSPs presents the possibility of 
contention between two bidirectional LSP requests traveling in opposite directions 
between two adjacent nodes. If there is no restriction on the ports/channels that can 
be used for bi-directional LSPs and if there are alternate resources, then both nodes 
will pass different labels upstream and the contention will be resolved naturally. If 
there is a restriction on the ports/channels that can be used for the bidirectional LSPs 
(for example if they must be physically coupled on a single I/O card), or if there are no 
more resources available, then the contention must be resolved by some other means. 
The current GMPLS signaling proposal suggests letting the node with the higher node 
ID win the contention. 

[0004] Unfortunately, current GMPLS proposals do not address the situation when a 

unidirectional LSP and a bidirectional LSP contend for the same resources. A network 
operator, in fact, may wish to offer both unidirectional and bidirectional high speed 
connections over the same network — without incurring the possible provisioning 
costs of segregating interfaces on network nodes between such connections. The 
above-mentioned prior art contention schemes for handling bidirectional and 
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unidirectional LSPs, however, are not consistent. Accordingly, there is a need for 
enhanced contention resolution procedures that can handle such situations. 

Summary of Invention 

[0005] Label contention in a label switched network is resolved by applying a contention 
resolution scheme that reconciles policies for handling unidirectional and bidirectional 
label switched path setup. In accordance with an embodiment of the Invention, label 
contention between a first label switched path setup message sent by a first node in a 
label switched network and a second label switched path setup message sent by a 
second node in the network is resolved by giving priority in accordance with a 
contention scheme that takes into account the nature of the respective setup 
messages. Priority can be given to the first label switched path setup message where 
the setup message is a label reply and the second label switched path setup message 
is a label request. Priority can also be given to the label switched path setup message 
for a bidirectional label switched path over setup messages for a unidirectional label 
I switched path. Where the setup messages are both for unidirectional label switched 

paths or both for bidirectional label switched paths, the contention can be 
1 advantageously resolved using different contention policies, e.g., using downstream 

I label selection or selecting the node with the higher node identification, respectively. 

J Thus, the present invention can be utilized to resolve inconsistent prior art contention 

I 

policies. 

[0006] Alternatively, in accordance with another embodiment of the invention, label 

contention between the first label switched path setup message sent by the first node 
in the label switched network and the second label switched path setup message sent 
by the second node in the network can be resolved by giving priority in accordance 
with the same contention policy for unidirectional and bidirectional label switched 
paths. For example, the node with the higher identification can be given higher 
priority, even where the nodes are requesting setup of unidirectional label switched 
paths. 

[0007] 

The contention resolution procedures disclosed in the present invention permit a 
network operator to offer bidirectional and unidirectional label switched paths over 
the same label switched network without a need to segregate the interfaces. These 
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and other advantages of the invention will be apparent to those of ordinary sl<ill in the 
art by reference to the following detailed description and the accompanying drawings. 

Brief Description of Drawings 

[0008] FIG. 1 is a diagram of two label switched nodes in a label switched network, 
exchanging label switched path setup messages. 

[0009] FIG. 2A is an abstract diagram of a generalized label request and FIG. 2B is an 
abstract diagram of a generalized label. 

[001 0] FIG. 3 is a flowchart of processing performed by a label switched network node, in 
accordance with a first embodiment of the invention. 

O [001 1] FIG. 4 Is a contention resolution table, in accordance with a preferred embodiment 
3l of the invention. 

tfl [0012] FIG. 5 is a flowchart of processing performed by a label switched network node, in 

f I i 

I ; 5 accordance with a second embodiment of the invention. 

|i Detailed Description 

tfl 

III [001 3] FIG. 1 is a diagram of two nodes 1 1 0 and 1 20 in a label-switched network, 
p illustrating an example of contention that can be handled by the present invention. 

The nodes 110, 1 20 are two out of a plurality of nodes connected in an arbitrary 
topology that permits connectivity between a plurality of ingress/egress nodes. For 
example and without limitation, the label-switched network can be an optical 
network, each node 110, 120 comprising an optical cross-connect and a wavelength 
division multiplexer terminal that multiplexes optical signals at different wavelengths 
into an optical fiber leading to another node. 

[0014] 

Each node has one or more channels/ports that connect it to an adjacent node in 
the network. Node 110 in FIG. 1 is shown as having two bidirectional I/O interfaces 
(i.e. a transmitter/receiver pair of ports). The first I/O interface is assigned label "1" 
for the transmitter port and label "2" for the receiver port. The second I/O interface is 
assigned label "3" for the transmitter port and label "4" for the receiver port. Similarly, 
there are two I/O interfaces in node 120. The first I/O interface is assigned label "7" 
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for the transmitter port and label "6" for the receiver port. The second I/O interface is 
assigned label "9" for the transmitter port and label "8" for the receiver port. 



[001 5] A label-switched path ("LSP") through the network is established using the 

exchange of label distribution messages between adjacent nodes, In accordance with 
an advantageous protocol such as RSVP-TE or CR-LDP. See, e.g., P. Ashwood-Smlth, 
et al., "Generalized MPLS — Signaling Functional Description," IETF Network Working 
Group, Internet Draft, http://www.ietf.org/internet-drafts/draft-ietf-mpls- 
generalized-signaiing-01 .txt (November 2000); L Berger, et al., "Generalized MPLS 
Signaling — RSVP-TE Extensions," IETF Network Working Group, Internet Draft, 
http://www.ietf-org/mternet-drafts/draft-ietf-mpls-generalized-rsvp-te-OO.txt 
(November 2000); D. Awduche, et al., "RSVP-TE: Extensions to RSVP for L5P tunnels," 



S IETF Network Working Group, Internet Draft, http://www.ietf.org/internet- 

fl drafts/draft-ietf-mpls-rsvp-lsp-tunnel-06.txt (July 2000); P. Ashwood-Smlth, et al., 

^11 "Generalized MPLS Signaling — CR-LDP Extensions," IETF Network Working Group,^ 

Internet Draft, http://www.ietf.org/internet-drafts/draft-ietf-mpls-generalized-cr- 
Idp-OO.txt (November 2000); and B. Jamoussi, et al., "Constraint-Based LSP Setup 
using LDP," IETF Network Working Group, Internet Draft, http://www.ietf.org/ internet- 



's a 
III 

III 



m 

f^ drafts/draft-ietf-mpls-cr-ldp-04.txt Quly 2000), which are incorporated by reference 



III 



[0016] 



herein. 



For example, in FIG. 1 , node 11 0 is depicted as requesting the setup of a 
unidirectional LSP between node 1 10 and node 120. Node 110 sends a label request 
101 to node 1 20, for example a REQUEST/PATH message that contains a generalized 
label request in the format shown in FIG. 2A. See, "Generalized MPLS — Signaling 
Functional Description," above. The node 110 includes a suggested label with the 
generalized label request, namely label "1" for the unidirectional LSPl , which allows 
node 1 10 to start configuring Its hardware immediately. Downstream node 1 20 can 
accept the proposed label or select an alternative label, in the format depicted in FIG. 
2B, and reply for example using a MAPPING/RESV message which includes the 
generalized label. In FIG. 1 , however, it turns out that node 1 20 is attempting to setup 
a bidirectional LSP between node 1 20 and node 1 1 0, This is accomplished by sending 
a REQUEST/PATH message suggesting a particular label for the path from node 1 20 to 
node 1 1 0 while including an "upstream" label object for the path from node 1 1 0 to 
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node 1 20. If accepted by node 1 1 0, this would result in two unidirectional 
channels/ports being assigned in a same-numbered pair (one cliannel/port~pair with 
the same number/ID in each direction). It is assumed in FIG. 1 that there exists some 
restriction on which ports/channels can be used for a bidirectional LSP, e.g., a 
bidirectional LSP requires a single I/O interface at node 110 and node 120.When node 
120 assigns the downstream label "6" and suggests label "7" for the bidirectional LSP2 
between node 1 20 and node 1 1 0, this results in a contention between the two 
proposed connections. 

[001 7] Suppose that L5P2 Is given priority in accordance with the downstream label 
selection rule for unidirectional LSPl . Node 1 20 can attempt to assign a new label, 
such as label "8" for LSPl . Suppose, however, that at the same time that node 1 20 
assigns label "8" for LSPl , node 1 1 0 assigns a downstream label "4" and suggests 
label "3" for another bidirectional LSP3 from node 11 0 to node 1 20. How is this 
contention to be resolved? Even if it is assumed that node 1 1 0 has a higher node ID 
than node 1 20 (e.g. node 1 1 0 is shown in FIG. 1 as having a node ID = 1 00 while 
node 1 20 is shown as having a node ID = 50), a new mechanism is needed to resolve 
this type of contention. 

[001 8] 3 f^j^pj ^ flowchart of processing performed by a node in the label 

switched network, in accordance with a preferred embodiment of an aspect of the 
invention. At step 301 , the node receives a LSP setup message, either a label request 
or a label reply, from another node in the network. At step 302, the node checks to 
see whether the received message will cause any contention with any label 
assignments/suggestions by the node. If not, then at step 311, there is no contention 
and the LSP setup message is processed normally. If there is contention for selection 
of one or more particular ports/channels, then at step 303, the node consults a set of 
contention resolution rules to decide which label message should "win" the 
contention. It is advantageous for the contention rules to be consistent with existing 
contention resolution procedures for unidirectional and bidirectional LSPs. Thus, in 
accordance with a preferred embodiment of the invention, the following rules can be 
used to decide which label wins the contention: 

(1) Downstream label selection for unidirectional LSPs; 

(2) Higher node ID for bidirectional LSPs; 



APP ID=10063923 



Page 6 of 19 



(3) Bidirectional LSPs liave priority over unidirectional LSPs; 

(4) LSP with label-reply has higher priority over LSP with label-suggestion. 
These contention resolution rules are illustrated at steps 304, 305, 306, and 307 in 
FIG. 3. As described in the background, the first two rules are advantageously 
consistent with existing GMPLS contention resolution procedures for unidirectional 
and bidireaional LSPs respectively. 

[001 9] The fourth rule is suggested by the nature of the LSP signaling process. In the 
GMPLS framework, as described above, both CR-LDP or RSVP-TE need two message 
waves to establish a LSP. The first one is some kind of label-request with or without a 
label suggestion. The second one is a label-reply. If there is a contention between a 
label-request (with a label suggestion) and a label-reply, the label-reply should be 
g allowed to win. The reason is that label-request still has a chance to select a new label 

on label-reply. 

p'l [0020] The third rule is suggested by the nature of bidirectional LSPs. If there is a 

contention between a unidirectional LSP and a bidirectional LSP, all other things being 

|;i equal, then the bidirectional LSP should be allowed to win. The rationale for this rule 

III 

%l is that a bidirectional LSP is "harder" to establish than a unidirectional LSP. A pair of 

ill 

4' nodes could be configured to give unidireaional LSPs priority over bidirectional LSPs, 



^11 although it is not clear that there is any advantage to allowing this flexibility. 

[0021] With reference again to FIG. 3, the node determines which label "wins" the 

contention, at step 308, using the contention resolution rules. If the label allocated by 
the node wins the contention, then, at step 309, the node is responsible for issuing an 
error message, e.g. a PathErr/NOTIFICATION message with a "Routing problem/Label 
allocation failureMndication. If the label allocated by the node loses the contention, 
then, at step 31 0, the node will receive such an error message and will need to 
allocate a different label(s) for the desired LSP. If no other resources are available, the 
node will need to proceed with standard error handling for such situations. 

[0022] 4 jg ^j^jji^ ^1^2^^ expands upon the above-mentioned contention resolution 

rules and reflects an embodiment/implementation of said rules. The table defines how 
contention is to be resolved at a node. The column headings indicate the LSP setup 
message that has been sent by the node. The rows indicate the message that has been 



APP_ID=10063923 



Page 7 of 19 



received by the node. "REQUEST — UNI" means a label request suggesting a label for a 
unidirectional LSP. "REQUEST — Bl" means a label request for a bidirectional LSP. 
"REPLY — UNI" means a label reply assigning a label for a unidirectional LSP. "REPLY — 
Bl" means a label reply for a bidirectional LSP. In the table, "OK" means that there 
should be no contention, in other words, conventional downstream label selection for 
unidirectional LSPs should resolve any possible contention. "Bl" means that the 
bidirectional LSP should win; and "REPLY" means that the label-reply should win. 
"MASTER" means that conventional bidirectional LSP contention rules should be used, 
e.g., the LSP with the label assigned by the higher node-id should win. 

[0023] FIG. 5 sets forth an alternative contention resolution scheme that 

disadvantageous^ results in a change to either the rule for unidirectional LSPs or for 
bidirectional LSPs. At step 501 , the node receives a label-request or label-reply 
III message from another node in the network. At step 502, the node checks to see 

W whether the received message causes any contention with any label 

ry assignments/suggestions by the node. If not, then at step 508, there is no contention 

i ■ 

' and the message is processed normally. If there is contention for selection of one or 

1 3 more particular ports/channels, then at step 503, the node decides which label 

ll message "wins" the contention by using the same contention rule for both 

j:| bidirectional and unidirectional LSPs. For example, as illustrated in FIG. 5, the node 

uses the bidirectional LSP contention resolution scheme — namely, determining which 
node has a higher node ID — for both bidirectional LSPs and unidirectional LSPs. As 
mentioned above, this has the disadvantage of changing the downstream label 
selection rule for unidirectional LSPs. Then, at step 505, if the label assigned by the 
node wins the contention, that node at step 506 issues an error message to the other 
node that assigned the label that lost the contention. Otherwise, at step 507, an 
alternate label must be allocated by the losing node upon receipt of the appropriate 
error message. 

[0024] yj^^ present Invention advantageously permits a network operator to offer 
unidirectional high speed connections over the same network infrastructure for 
bidirectional high speed connections. For example, customers for unidirectional 
connections could be Internet Service Providers (ISPs) or other data service providers 
who only want to pay for the transport of router links In one direction. Indeed, such 
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applications are required in OIF UNIT .0, ODSI signaling control specification, and IETF 
GMPLS framework. 



[0025] The foregoing Detailed Description is to be understood as being In every respect 
illustrative and exemplary, but not restrictive, and the scope of the invention disclosed 
herein is not to be determined from the Detailed Description, but rather from the 
claims as interpreted according to the full breadth permitted by the patent laws. It is 
to be understood that the embodiments shown and described herein are only 
illustrative of the principles of the present invention and that various modifications 
may be implemented by those skilled in the art without departing from the scope and 
spirit of the invention. For example, the detailed description describes an embodiment 
5 : of the invention with particular reference to GMPLS. However, the principles of the 

O present invention could be readily extended to other label switched protocols which 

g| permit unidirectional and bidirectional label switched paths. Such an extension could 

' ^f be readily implemented by one of ordinary skill in the art given the above disclosure. 

ill 

CI 

m 
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